Clean Architecture
概要
Clean Architecture は Robert C. Martin が考えたソフトウェアアーキテクチャである。
サイズが肥大化しても開発速度が低下しないソフトウェアの実現を目指している。
関心事の分離を目的とする以下のアーキテクチャを 1 つにまとめあげたものとして考案された。
Hexagonal Architecture
DCI
BCE
ソースコードを複数の層に分ける関心事の分離手法が Clean Architecture に特徴的である。
複数の層の組み合わせによってアプリケーションが構築される様子は、下図のように同心円の図で表すとわかりやすい。
https://gyazo.com/4b0b1aeb0b7c893d49622079d3de191c
Celan Architecture はソースコードの依存関係の方向性を限定する依存性のルールを定めている。
依存性のルールは以下の通りである。
ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければいけない。
Clean Architecture は依存性のルールによって フレームワーク・ライブラリ・DB・UI に対するソフトウェアの過度な依存を防ぎ、ソフトウェアの変更がソースコードに変更を及ぼす範囲を小さくして、変更を容易にしたいと目論んでいる。
小話
依存性のルールを守らず fp-ts と結婚した俺達は
Clean Architecture に則って開発されるソフトウェアのソースコードは、自身より内側の層にあるソースコードにのみ依存するべきである。
所感として、依存性のルール遵守自体が効力を持つというよりは、ソースコードの依存方向に対して気を払って開発する姿勢が開発速度を保つような気がする。
依存方向に対して気を払わなかった例としてfp-ts すきすきオタク事件がある。
fp-ts を使うのがきもちよすぎてあちこちで使いまくった結果、「内側の層の返り値が fp-ts の TaskEither であることを期待する外側の層」がたくさんできあがった。 ライブラリは Clean Architecture の一番外側の層にあるべきものなので、この状態は Clean Architecture の規則的に大変良くない。
実際上の問題として、「fp-ts に破壊的変更を伴う更新が起きたが、fp-ts のバージョンを上げると変更範囲が大きくなりすぎるのでバージョンを上げられない」という問題が起きてしまった。
フレームワークに対する過度な依存を Robert C. Martin は結婚と表現している。（Clean Architecture 第 32 章）
今回の fp-ts のバージョン上げは急を要する問題ではないが、例えばあるライブラリのセキュリティ上の課題を解決するようなバージョンアップに迅速に追随できないようだと今後困りそうだ。
結婚は良くない。俺たちはそう思った。